feat: carry --metadata-file through the bake build strategy - #733

python-on-whales 0.81.0 added metadata_file support to
docker.buildx.bake(), matching the existing docker.build() support.
Wire bakery build --metadata-file through the --strategy bake path:

- BakePlan.build() now accepts metadata_file and forwards it to
  `docker buildx bake --metadata-file`.
- BakeryConfig.build_targets()'s BAKE branch passes metadata_file
  through to BakePlan.build() and, on success, loads the resulting
  file back into each target's build_metadata (buildx bake writes one
  entry per target keyed by the same UID used in the bake plan, so no
  merge step is needed, unlike the BUILD strategy).
- Bump python-on-whales lower bound to >=0.81.0.

Refs #728

The `bake` and `build` strategies produce metadata files from entirely
separate code paths -- raw `docker buildx bake --metadata-file` passthrough
vs. `BakeryConfig._merge_sequential_build_metadata_files()` -- yet
`bakery dgoss run --metadata-file` and `bakery ci publish` consume both
through the same loader. Nothing pinned that equivalence, so a divergence
would surface as a broken publish in CI rather than a test failure.

Adds the two real metadata files captured while comparing the strategies
(package-manager 2026.06.0, 6 targets, linux/amd64, --push with a temp
registry) as fixtures, and a parametrized test class asserting the contract
consumers depend on: UID-keyed top level, resolvable `<name>@sha256:...`
image refs, `platform == linux/amd64`, `created_at` resolving from the
descriptor annotation rather than the `datetime.now()` fallback, and
matching UID/tag sets across the two producers.

Also documents the multi-platform degradation: one invocation building
several platforms yields an index descriptor with no platform, so
`platform` is None and dgoss/merge lose per-platform selection.

Closes #740